We need to do this with folders like out/ and node_modules/ too. There should be a very lightweight, file-count-wise, package at the end of the line, because everything is meant to be bundled into one file.

If I remove node_modules, the generated extension does not work. Also, the out is needed because that is where our extension is compiled to, which is our entrypoint. I dont think we can discard these two dirs.

Did some more testing just to validate what I recalled from last week ;) :

• If I remove out/, then the package wont be generated because it complains of a missing entry point (main in package.json defines it as /out/extension.js
• If I remove node_modules/, then the generated package is only 20k, but fails to launch at runtime because:

2023-06-26 11:19:33.659 [error] Error: Cannot find module '@salesforce/lwc-dev-mobile-core/lib/common/CommonUtils'
Require stack:
- /Users/dbreese/.vscode/extensions/salesforce.salesforcedx-vscode-mobile-0.0.1/out/extension.js
- /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/loader.js
- /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap-amd.js
- /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap-fork.js

Yeah I'm basically fiddling around in my environment, seeing similar things.

There's a gap of documentation about some of the entries in your standard package.json file vs. what esbuild is / might be expecting. For example, I switched locally to have esbuild use an --outfile value of dist/main.js just to see how it went. And while it generates an all-in-one dist/main.js, it still complains at runtime about trying to use out/extension.js, which is the main entry point in package.json.

The dearth of comprehensive documentation is...frustrating. I'm going to keep poking around.

if you just change --outfile to out/extension.js it should work though so that it matches package.json's main value?

Yeah but I didn't like that because that's where we compile everything out too, and so you have to do a bunch of filtering to not include a swathe of JS files down there.

Locally, I ended up specifying --outfile as dist/main.js, and made that my main target in package.json too, and that got past that particular hurdle (and onto another one, but that's another story).

I'm not seeing the output file of the bundling process. You don't specify --outfile here. I think you need to?

No, I am using--outdir so it is just generated there as extension.js which includes bundled src from all of our source files.

I'd like to see some changes here. Gonna mention some files outside of this one too.

• Tack to --outfile from --outdir. The latter is if you need to call multiple targets within a package, which we don't.
• In my experience, the only two --external: directives we need are vscode and @oclif/core: the former because it won't get resolved, and the latter because it tries to access a relative-pathed package.json that doesn't otherwise exist in the right place, when the package is inlined into extension.js. The other --external: directives can go away, as we're including all of node_modules/—or rather, not excluding it—in .vscodeignore.
• Speaking of .vscodeignore: we should ignore all of out/, and bang-include (whitelist) !out/external.js. We don't need the other artifacts in there—esbuild will incorporate them into the external.js end product. And the leftover code could negatively impact the bundle at runtime in unforeseen ways.

Cool, let me try and update this.

I also updated the build so that it runs a clean, so the out directory SHOULD BE empty. However, perhaps vscode instance could do a concurrent compile and shove *.js files in there too. I'll try the !out/extension.js approach.

If I change the --external:* paths to just have vscode and @oclif/core, the result extension.js bundle is 2.4megs. Leaving in what I have, it is only 10k. I am trying to figure out what exactly it is bundling.

If I remove the --external:* options (except for vscode and @oclif/core, and also ignore node_modules/*, then the extension does not work at all. It will install, but immediately shows error when launched.

I am still not sure WHY removing these --external:* options makes the out/extension.js file be so much larger - presumably it is trying to bundle at least PARTS of the dependencies?

It does appear that it is attempting to bundle some things in node_modules: grep ^// extension.js shows the file paths such as:

// node_modules/@salesforce/ts-types/lib/narrowing/is.js
// node_modules/@salesforce/ts-types/lib/narrowing/as.js
// node_modules/@salesforce/ts-types/lib/errors.js
// node_modules/@salesforce/ts-types/lib/narrowing/to.js
// node_modules/@salesforce/ts-types/lib/narrowing/assert.js
// node_modules/@salesforce/ts-types/lib/narrowing/coerce.js
// node_modules/@salesforce/ts-types/lib/narrowing/ensure.js
// node_modules/@salesforce/ts-types/lib/narrowing/has.js
...

and also ignore node_modules/*

We can't ignore node_modules/ in this iteration. That requires more fine tuning of --external: directives than we're going to bite off in V1, to ensure that all of the dependencies of any --external: directives are also external. I started playing with that, but it's painful and probably needs automation to be maintainable.

But in the absence of adding any .vscodeignore directives for node_modules, you should be able to attenuate your --external: directives to the two I listed.

I am still not sure WHY removing these --external:* options makes the out/extension.js file be so much larger - presumably it is trying to bundle at least PARTS of the dependencies?

Correct. When packages are not otherwise called out with --external: directives, esbuild interrogates and inlines all of those packages and their dependencies into extension.js. That's why that file gets bigger—otherwise, --external: packages just continue to live on their own in node_modules/, and extension.js refers to them in a more normal require type of way in those cases.

I also updated the build so that it runs a clean, so the out directory SHOULD BE empty. However, perhaps vscode instance could do a concurrent compile and shove *.js files in there too. I'll try the !out/extension.js approach.

Oh that's a good point: esbuild may only generate extension.js, at which point cleaning beforehand effectively gets us to the same place. I was thinking esbuild would generate the same output as e.g. tsc does for us in development.

Shouldn't npm prune --omit=dev happen before the bundle:extension step? Or otherwise if that doesn't work with stuff put together all in this one prepublish step, perhaps this step should be broken out to first build, then omit, and then bundle.

Otherwise, I don't see the prune step doing anything for us here.

I thought the same thing yesterday, but i believe what is happening is prepublish runs, then bundling occurs, THEN the packaging occurs. If I change these around, the prune will remove all dev-deps and then esbuild wont even be found. I also tested it yesterday by adding a && ls -la to the end of bundle:extension and no *.vsix file exists after esbuild executes.

Yeah, I figured simply changing the order would probably break things. I think you'd need to do a build step, then an omit step, and then a bundle step. Right now the "build and bundle" is all merged together in one command, so it's not possible.

It's not a big deal though, either way. I'm okay leaving it as is for this release.

Your script creation is slightly different than the doc example, but piecing it together: should we have the --sourcemap option in here too?

Ah, let me try adding it. I have gone through so many iterations of the esbuild commands, not sure how I arrived at this one, but other than the --sourcemap, looks close unless I'm missing something?

It looks pretty much the same as the example, otherwise. I like the way the example in the docs is split out, because it also provides a target for being able to debug. But we can also cover that split-out in our next iteration of bundling to come. I'm okay with it as we've coded it today. Presumably --sourcemap won't negatively impact what we have here.

Oh I just noticed I looked at it wrong! In the example configuration, vscode:prepublish calls the esbuild-base script, which does not specify --sourcemap. The esbuild script—which is not otherwise called in the publishing workflow—calls esbuild-base, but with the --sourcemap argument added on.

So presumably --sourcemap not necessary for actual publishing, and is probably more useful in local use cases?

I understand it is more for generating the mapping from minified to debug code, similar to a dsym on iOS or mapping.txt for Android proguard obfuscation? It is being generated, but not bundled in the VSIX currently.

Exactly: it's meant to tie back to code in a development environment, to facilitate stepping through minified code, or JS code transpiled from TypeScript, etc. It's not required for runtime functionality, just for debugging it. So they don't have any real purpose in your final bundle. 👍